The author reflects on their experience with the Rust programming language, likening it to the first generation of the iPhone—innovative but incomplete. Initially captivated by Rust's features such as memory safety and a modern package manager, the author expresses frustration after four years of use, feeling that the language has stagnated. They note a significant slowdown in the introduction of new features, with many promising ideas, like coroutines, remaining unimplemented despite being in the pipeline for years. The author suggests that the Rust community's consensus process has become unwieldy, leading to a graveyard of good ideas that never see the light of day. The author fantasizes about forking the Rust compiler to create a new version of the language, which they refer to as "seph." They propose several changes, starting with the introduction of function traits, which would allow developers to specify properties of functions, such as whether they can panic or if they are pure. This would enhance the language's ability to guarantee certain behaviors at compile time, addressing concerns like ensuring that specific blocks of code do not panic. Another significant proposal involves implementing compile-time capabilities to mitigate supply chain risks associated with third-party crates. The author suggests that functions interacting with sensitive operations, like file system access, should be marked with capabilities that require explicit whitelisting in a project's configuration. This would prevent potentially malicious code from being executed without the developer's knowledge. The author also critiques the complexity of Rust's Pin and borrow checker, arguing that the current implementation complicates the language unnecessarily. They propose a more intuitive system that would allow developers to express borrowing semantics directly in their code, making it easier to work with self-referential structures and async functions. Additionally, the author expresses admiration for Zig's compile-time capabilities, suggesting that Rust could benefit from a similar approach that allows developers to write compile-time code using the same syntax as regular Rust. They also list smaller improvements they would like to see, such as better ergonomics for raw pointers and enhancements to the language's collection types. In closing, the author acknowledges that many of their proposed changes would be incompatible with existing Rust, potentially requiring a new edition of the language. They express reluctance to engage with the RFC process, feeling that it often leads to frustration and unfulfilled ideas. Ultimately, they contemplate the possibility of forking Rust to implement their vision, though they recognize the challenges involved in such an endeavor.

This is a long collection of thoughts and problems that two indie developers faced when trying to use Rust for game development after completing development of several games written in Rust. They conclude that Rust presents fundamental challenges to game development, even after one becomes experienced with it. For example, Rust's borrow checker often requires code restructuring for even basic tasks, leading to a frustrating development experience. Also, Rust's focus on refactoring and correctness can lead to over-engineered solutions that prioritize code purity over being able to ship the game to a playable state quickly.

Strong types in programming languages like C++ and Rust, which enforce specific data types and rules for variables, lead to fewer bugs, more expressive APIs, and potentially better performance. They prevent invalid input, improve code clarity, and reduce the need for repetitive error checking (like in JavaScript with undefined).

This article explores how to implement Rust's Result and Option types in TypeScript to make error handling and null value management easier.

Microsoft has donated $1 million to the Rust Foundation to support the language's infrastructure and fellowship program and to help ease the workload of maintainers.

Google has published a whitepaper that outlines its "Secure by Design" approach, which advocates for the adoption of languages like Java, Go, and Rust to achieve high-assurance memory safety. Google has a massive C++ codebase. It will gradually adopt memory-safe languages for new code while seeking safety improvements for existing C++.

The Safe C++ Extensions proposal, recently published by the C++ community, aims to address the challenge of ensuring that C++ code is free of memory safety bugs. Private and public sector organizations have been pushing programmers to write new applications and rewrite old ones in memory safe languages over the past two years. The majority of serious vulnerabilities in large codebases come from memory safety flaws. The Safe C++ project adds new technology for ensuring memory safety, preventing users from writing unsafe code. It allows existing code to work as always and ensures stakeholders have control for incrementally opting into safety.

Functional programming languages should embrace mutation more effectively, as current approaches have significant drawbacks. This author critiques existing options, including allowing unrestricted mutation, limiting mutation to specific regions, and using linearity. A fundamentally new approach that addresses the shortcomings of current methods and integrates well with existing state management solutions is needed.

This developer was able to optimize CRDTs (Conflict-Free Replicated Data types) for collaborative editing by 5,000x. They started with a simple data structure change using a flat list instead of a tree. Then they adopted a bidirectional linked list and run-length encoding, leading to a 30x speedup compared to the original Automerge implementation. Finally, by using Rust's memory control capabilities and a range tree data structure, the developer achieved a 5,000x speedup, demonstrating that CRDTs can achieve performance comparable to native strings.

Java is evolving to incorporate concepts popularized by Rust, such as immutable data structures by default and algebraic data types. These changes were inspired by Rust's emphasis on compile-time safety guarantees. Developers can now define immutable records in Java. Java's new sealed interfaces and exhaustive switch syntax enable the use of algebraic data types so that code handles all possible states of a variable in a type-safe manner.

June is a new systems programming language that aims to be easier to learn and use than Rust. It simplifies memory management using grouped allocations, so related data shares a single lifetime rather than tracking individual lifetimes as in Rust.

The design of strings in Rust and Julia are different. Rust enforces UTF-8 validation, while Julia allows invalid UTF-8. Rust treats all code as production-quality, while Julia encourages hacking and prototyping. Julia's flexibility with string encodings is often more practical and efficient.

The debate between using threads and async/await in Rust revolves around simplicity, performance, and composability. While threads may offer familiarity and straightforwardness, async/await is better in I/O-bound scenarios due to its composable code.

Exceptions are a superior error handling mechanism compared to returning error values. This is because exceptions offer a better user and developer experience by providing more graceful error handling and leading to faster execution. The common practice of using error values in languages like Rust and Go leads to excessive boilerplate and has a higher potential for hidden system errors.

Python's "everything is an object" philosophy slows down the parsing of large codebases with the ast module due to the overhead of converting C structs to Python objects. This conversion results in excessive memory allocations and garbage collection. To address the issue, this developer implemented a Rust extension that processed the ASTs in Rust, only returning the final results to Python, resulting in a 16x speedup and significantly reduced memory pressure. They argue that Python extensions should be designed to be lazy, meaning that they should only create Python objects when explicitly required, and instead keep data in a compact, optimized format within their own language.

Memory safety vulnerabilities pose a significant challenge to software security, and Google is actively addressing this issue through a strategy known as Safe Coding. This approach emphasizes the transition to memory-safe programming languages as a means to reduce vulnerabilities at their source. The blog post, authored by Jeff Vander Stoep and Alex Rebert, outlines the rationale behind this strategy and presents data demonstrating its effectiveness, particularly in the context of Android development. The authors highlight that focusing on Safe Coding for new code can lead to a surprising reduction in overall security risks, even as the amount of memory-unsafe code increases. This counterintuitive outcome is attributed to the nature of vulnerabilities, which tend to decay over time. Research indicates that most vulnerabilities are found in new or recently modified code, suggesting that by prioritizing memory-safe languages for new features, the overall density of vulnerabilities can decrease significantly. The blog provides a detailed analysis of the transition that the Android team began around 2019, driven by the rising costs and complexities associated with managing memory safety vulnerabilities. Over a six-year period, the percentage of memory safety vulnerabilities in Android dropped from 76% to 24%, a notable improvement that aligns with the shift towards memory-safe languages. The authors discuss the evolution of strategies to combat memory safety vulnerabilities, categorizing them into four generations. The first generation focused on reactive patching, which proved costly and insufficient. The second generation involved proactive mitigations, which raised the cost of exploitation but also imposed performance overhead. The third generation emphasized proactive vulnerability discovery through tools like sanitizers and fuzzing, yet these methods often addressed symptoms rather than root causes. The fourth generation, which Google is now pursuing, centers on high-assurance prevention through Safe Coding. This approach integrates security directly into the development process, leveraging language features and static analysis to create a secure-by-design ecosystem. By establishing a baseline of security through memory-safe languages, the goal is to reduce vulnerability density and improve overall software quality. The blog also emphasizes the importance of interoperability between memory-safe and memory-unsafe languages, allowing for a gradual transition without the need to rewrite existing code. Google has invested in tools and initiatives to facilitate this interoperability, such as grants to the Rust Foundation and the development of interoperability tooling. As Safe Coding continues to reduce risks, the authors anticipate a shift in the reliance on traditional mitigations and detection methods. They expect that as more code transitions to memory-safe languages, the need for exploit mitigations will decrease, leading to more efficient software. Additionally, proactive detection methods like fuzzing may become more effective as they can be applied to smaller, well-encapsulated code segments. In conclusion, the blog post underscores the importance of adopting Safe Coding practices to combat memory safety vulnerabilities effectively. By focusing on prevention and leveraging the natural decay of vulnerabilities, Google aims to enhance the security of its software products, particularly within the Android ecosystem. The commitment to secure-by-design principles is expected to yield long-term benefits in reducing vulnerabilities and improving overall software safety.

This article discusses the role of Python, Go, and Rust in AI application development: Python for AI model development, Go for scaled-up production, and Rust for performance-critical tasks. It suggests that Go could be the production language alternative to Python, emphasizing the importance of selecting the right language for the task based on the ecosystem and tool suitability. The author advocates for bridging Python and Go communities to enhance AI application production.

This developer expresses their fondness for Go but also lists features they miss from other languages. They find the lack of ordered maps in Go's standard library inconvenient, requiring developers to use third-party implementations or manually sort maps. The developer also misses keyword and default arguments for functions, which would simplify function calls and improve API design. They also wish there was lambda syntax in Go.

Memory safety vulnerabilities pose a significant challenge to software security, and Google is actively addressing this issue through a strategy known as Safe Coding. This approach emphasizes the transition to memory-safe programming languages as a means to reduce vulnerabilities at their source. The belief is that by focusing on Safe Coding for new code, the overall security risk of a codebase can be significantly diminished, leading to a notable decline in memory safety vulnerabilities. The blog post highlights a remarkable statistic: the percentage of memory safety vulnerabilities in Android has decreased from 76% to 24% over a six-year period, coinciding with a shift towards memory-safe languages. This transition is not just a theoretical exercise; it has practical implications that can be observed in the Android codebase. A key insight shared is the counterintuitive nature of the results. As new development increasingly incorporates memory-safe languages, the overall number of memory safety vulnerabilities declines, even as the amount of memory-unsafe code grows. This phenomenon can be explained by the concept of vulnerability decay, where vulnerabilities tend to reside in newer or recently modified code. As older code matures, it becomes less prone to vulnerabilities, leading to an overall reduction in risk. The Android team began prioritizing memory-safe languages around 2019, driven by the rising costs and complexities associated with managing memory safety vulnerabilities. The results have been promising, with a continued decline in memory safety vulnerabilities observed in 2024. This decline is attributed to the correlation between the programming languages used for new code and the prevalence of memory safety issues. The blog also outlines the evolution of strategies to combat memory safety vulnerabilities over the years. The first generation focused on reactive patching, which proved costly and insufficient. The second generation introduced proactive mitigations, but these often came with performance overhead and did not fully address the root causes. The third generation emphasized proactive vulnerability discovery, yet still fell short of providing high assurance. The fourth generation, which Google is now embracing, is centered around high-assurance prevention through Safe Coding. This approach integrates security directly into the development process, allowing for continuous assurance and reducing the likelihood of introducing vulnerabilities. By leveraging memory-safe languages and focusing on secure-by-design practices, Google aims to break the cycle of constant vulnerability management and instead foster a more secure development environment. Interoperability is highlighted as a crucial aspect of this transition. Rather than discarding existing memory-unsafe code, Google is working on making interoperability between memory-safe and unsafe languages seamless. This strategy allows for incremental improvements while capitalizing on existing code investments. As Safe Coding continues to reduce risks, the reliance on previous generations of security measures is expected to diminish. The focus will shift towards more selective use of mitigations and enhanced effectiveness of proactive detection methods. In conclusion, the adoption of Safe Coding represents a paradigm shift in how software security is approached. By prioritizing memory-safe languages and integrating security into the development lifecycle, Google is not only addressing current vulnerabilities but also setting a foundation for a more secure future in software development. The ongoing efforts and results from the Android team serve as a testament to the effectiveness of this strategy, with further insights and developments anticipated in the coming months.

This blog post contains advice on building a browser engine that's competitive with Chromium. Focusing on the right set of imparted and hard use cases will help a lot in the beginning. Some of these constraining use causes include site isolation, content main thread sanctity, fast JS-DOM calls, page load performance, and typing latency. The post also contains ideas on how browsers can be improved in general. For example, they could restore state after a browser reset.

This developer, who completes Advent of Code in a new programming language every year, chose Zig for 2023 and found it to be a modernized C with a unique approach to error handling and type manipulation. Zig's standout features include detectable illegal behavior and comptime, which offer improved error detection and type-level programming capabilities respectively. However, Zig could benefit from enhancements in developer experience, including a better language server, clearer error messages, and improved documentation.

This is a practical guide to refactoring a messy React component through gradual improvements. First, one should make sure that tests are written so that no functional changes occur during refactoring. Then, linting rules should be used to prevent future code duplication and dead code. The guide highlights several key areas for refactoring, including splitting components based on responsibilities and extracting utility functions to improve code organization and maintainability.

This author built a large-scale service and found certain principles reappearing throughout the implementation. It's useful to prioritize a single source of truth and minimize mutable state when building something from scratch. Developers should also make sure not to abstract things prematurely and not to overuse mocks when writing tests for their code.

This article discusses the results of the 14th annual Stack Overflow Developer Survey. This year's most popular technologies are JavaScript and PostgreSQL. Rust and Markdown are the most admired. Developers are frustrated with technical debt at work, but they don't see AI as a threat. While most developers use or plan to use AI tools, many don't trust the accuracy of the technology.

Python continues to lead IEEE Spectrum's 2024 programming language rankings, driven by its dominance in AI and education, while SQL remains highly sought after by employers. Rising stars include TypeScript and Rust, with the latter gaining attention for its memory safety features.

The blog post by Arne Bahlo expresses a growing appreciation for tools that function effectively without requiring extensive configuration. This sentiment is particularly relevant in the context of software development, where many tools demand significant setup time and effort. Bahlo highlights the contrast between customizable tools, like Emacs, and those that are ready to use right away, emphasizing the appeal of the latter. Bahlo begins by referencing Julia Evans' praise for the fish shell, which is designed to work without the need for configuration. The fish shell includes features such as autosuggestions by default, which are often reliant on plugins in other shells like ZSH. This ease of use is reflected in Bahlo's own minimal configuration for fish, which consists mainly of abbreviations and two plugins that require no additional setup. The discussion then shifts to Helix, a code editor that Bahlo has adopted after struggling with a complex Neovim configuration that involved multiple external plugins. Helix stands out for its built-in support for features like Language Server Protocol (LSP) and tree-sitter, which enhance coding efficiency without the need for extensive configuration. Bahlo shares his simple configuration for Helix, which consists of just a few lines of code, demonstrating how streamlined the setup process can be. Lazygit is another tool Bahlo praises for its user-friendly design, allowing for effective Git management without the need for configuration. He appreciates its intuitive interface and the ease with which users can navigate its features. Bahlo also mentions Zellij, a terminal multiplexer that offers a similar no-configuration experience. It allows users to create layouts and manage panes without additional plugins, with a standout feature being the ability to toggle floating panes, which enhances workflow. The post concludes with a call for readers to share their own zero or minimal configuration tools, fostering a community of developers who value simplicity and efficiency in their tools. Bahlo encourages developers to prioritize a seamless default experience in their creations, reflecting a broader trend towards user-friendly software solutions. Overall, the blog post serves as a celebration of tools that prioritize ease of use, highlighting how they can enhance productivity and reduce the friction often associated with software setup.

The content explores various lesser-known tricks, quirks, and features of the C programming language, aimed at both novice and experienced developers. It highlights aspects that can often confuse even seasoned programmers, presenting them in a casual, unordered format with brief explanations and examples. The discussion begins with the concept of array pointers, explaining how arrays decay to pointers and the implications of this behavior. It also touches on the comma operator, which allows multiple expressions to be evaluated in a single statement, emphasizing that only the last expression's value is returned. Next, the text introduces digraphs and trigraphs, which are alternative representations of certain characters in C, designed to enhance portability across different character encodings. The designated initializer feature is also covered, allowing developers to initialize specific elements of structures or arrays in any order, which can improve code clarity. Compound literals are discussed as a way to create unnamed objects with specific values, while also noting that they can be treated as lvalues, allowing their addresses to be taken. The concept of escaping shadowing is illustrated with an example that demonstrates how to access a variable from an outer scope. The content continues with multi-character constants, which are implementation-dependent and generally discouraged, but can serve as self-documenting enums. Bit fields are introduced as a means to define members of a structure with specific bit widths, and the use of zero-length bit fields is explained as a way to create boundaries between other bit fields. The volatile and restrict type qualifiers are discussed, highlighting their roles in informing the compiler about variable access and optimization opportunities. The register type qualifier is mentioned as a hint to the compiler to store variables in faster memory locations, although its relevance has diminished with modern compilers. Flexible array members are explained as a way to create dynamic arrays within structures, while the %n format specifier in printf is introduced as a means to retrieve the current output position. Other format specifiers are briefly mentioned, along with the concept of interlacing syntactic constructs, which can lead to unexpected behavior in code. The text also covers the use of the "operator" for decrementing and comparing values in a single expression, the syntactic sugar of array indexing, and the unconventional use of negative array indexes for debugging purposes. Constant string concatenation and backslash line splicing are presented as techniques for managing string literals in a more readable manner. Using logical operators as conditionals is highlighted, showcasing how they can be employed in a manner similar to shell scripting. Compile-time checks using enums are introduced as a way to enforce certain conditions during compilation. The content further explores ad hoc struct declarations, the peculiarities of nested struct definitions, and flat initializer lists. Implicit casting of void pointers is explained, along with the static array indices in function parameter declarations, which can aid in optimization. Macro overloading by argument list length is discussed, demonstrating how macros can be defined to handle different numbers of arguments. The text also delves into function types and the oddities surrounding function designators and pointers. X-macros are introduced as a powerful preprocessor technique, while named function parameters are presented as a way to enhance function calls with clarity. The combination of default, named, and positional arguments is explored, showcasing how to create flexible function interfaces. The use of unions for grouping related fields is discussed, along with the concept of unity builds, which can simplify the build process but may hinder modularization. Matching character classes with sscanf() is presented as a way to perform simple pattern matching. The content concludes with mentions of garbage collection libraries, the Cosmopolitan Libc project, inline assembly, and techniques for evaluating sizeof at compile time. It also touches on detecting constant expressions, object-oriented programming in C, and safe variadic functions. Metaprogramming and the capabilities of the C preprocessor are highlighted, emphasizing its complexity and potential for creative solutions. Overall, the text serves as a comprehensive exploration of C's intricacies, encouraging developers to delve deeper into the language's capabilities and nuances.

This article presents a method for optimizing TypeScript type checking performance by using a systematic approach of branching, adjusting code, and measuring the impact with benchmarking tools.

GitHub introduced a beta for code-scanning autofix, merging GitHub’s Copilot with CodeQL to detect and automatically remedy security vulnerabilities in JavaScript, TypeScript, Java, and Python.

The 2024 Stack Overflow Developer Survey revealed that JavaScript and PostgreSQL remain the most popular technologies, while Rust and Markdown are the most admired. Developers are increasingly frustrated by technical debt at work, but they don't perceive AI as a threat to their jobs. Although 76% of developers are using or planning to use AI tools, many remain skeptical about their accuracy and ability to handle complex tasks.